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Sir: 

This Appeal Brief is submitted in support of the Notice of Appeal filed February 17, 
2004. This is an appeal from the Final rejection mailed November 18, 2003 (paper #14). 


I. REAL PARTY IN INTEREST 


Oracle Corporation is the real party in interest. 


04/21/2004 HftHHEDl 00000070 09454515 

01 FC:1402 330.00 OP 


LONNROTH, Sen No. 09/454,515 GAU 2176, Examiner Nguyen, Chau 
APPEAL BRIEF 

II. RELATED APPEALS AND INTERFERENCES 

Appellants are unaware of any related appeals and interferences. 

III. STATUS OF CLAIMS 

Claims 1-37 are pending in the application. 

Claims 1-37 have been rejected in the Office Action mailed August 21, 2003. 
Specifically, claims 1-5, 8-11, 14-17, 21-24, 27-30, and 33-37 are rejected under 35 U.S.C. § 
103(a) as allegedly unpatentable over Nagatomo et al. (U.S. Patent No. 6,334,126) in view of 
Lincke et al. (U.S. Patent No. 6,397,259). 

Claims 6, 7, 12, 13, 18-20, 25, 26, 31, and 32 are rejected under 35 U.S.C. § 103(a) as 
allegedly unpatentable over Nagatomo et al. in view of Lincke et al. further in view of Bayeh 
et al. (U.S. Patent No. 6,012,098). 

IV. STATUS OF AMENDMENTS 

There are no outstanding amendments. 

V. SUMMARY OF THE INVENTION 

1) Background 

As background, a web server is a computer that serves up web pages. A gateway is a 
computer or software on a computer in a network that serves as an entrance to another 
network. Extensible Markup Language, XML is a protocol developed by the World Wide 
Web Consortium. XML allows designers to create their own customized tags, enabling the 
definition, transmission, validation, and interpretation of data between applications and 
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between organizations. Wireless Application Protocol (WAP) is a secure specification that 
allows users to access information instantly via handheld wireless devices such as mobile 
phones. WAP supports most wireless networks. WAP-enabled devices that use displays and 
access the Internet run what are called microbrowsers - browsers with small file sizes that 
can accommodate the low memory constraints of handheld devices and the low-bandwidth 
constraints of a wireless network. Although WAP supports HTML and XML, the Wireless 
Markup Language (WML) (an XML application) is specifically devised for small screens 
and one-hand navigation without a keyboard. WML is an language used to specify content 
and user interface for WAP devices. 

2) Overview 

Figure 2 is a block diagram that illustrates a system 200 that implements an 
embodiment of the invention.. System 200 includes a mobile device (phone 210) that 
communicates with a gateway 202 over a network 212. According to one embodiment, 
phone 210 is a WAP phone that is configured to support the display of WML pages. In such 
an embodiment, gateway 202 is a WAP gateway configured to communicate with phone 210 
by sending WML pages through network 204 using the WAP protocol 

System 200 further includes a pre-processor 240, an XML processor 242, and a post 
processor 244. In general, pre-processor 240 receives requests from clients and generates 
request objects based on the request received. In one embodiment, the request objects are 
XML documents. The XML document "requests" are forwarded to XML processor 242 
which obtains XML documents from one or more XML sources (e.g., EML source 232, web 
server 1 10 or the database associated with XML gateway 232) to which XML processor 242 
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is connected. Those XML sources may include one or more gateways connected to non- 
XML sources. The XML documents that are created in response to the requests are passed to 
post processor 244 to be filtered and formatted according to the needs of the requesting 
entity. The conversion operation performed by post processor 244 is driven by XSL style 
sheets 250. Documents produced by post processor 244 are then delivered to the requesting 
entity. 

3) More Details About the Claimed Invention 

In other words, a method and apparatus is used for retrieving information from one or 
more data sources, in which a request for a service, such as viewing a web page, is received 
at a system (such as the system formed by preprocessor 240, XML processor 242, and 
postprocessor 244) from a particular type of client (such as phone 210) by a particular user. 
The service may be any of a variety of services such as obtaining information from a web 
site, performing a search, tracking package deliveries (as described in page 8,line 5, through 
page 9, line 4). The system (e.g., preprocessor 240, XML processor 242, and postprocessor 
244) is located separately from the client, and may be separated from the client by other 
systems such as gateway 202. Within the system (e.g., via preprocessor 240) a request object 
is generated based on a first set of parameters, which may be in the form of an XML request 
document, for example (see for example the paragraph bridging page 8 and 9 for a discussion 
of request objects). The first set of parameters includes the identity of the service (e.g., a 
URL for a web page or an identity indicating the performance of a package tracking service). 
In an embodiment, the first set of parameters for generating the request object also includes 
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the identity of the particular user. (Preprocessor 240 is discussed further on page 9, line 6, 
through page 10, line 14.) 

The system (e.g., via XML processor 242) transmits requests to one or more data 
sources (e.g., XML source 230, web server 1 10 of the database associated with XML 
gateway 232) based on the request object (e.g., received from preprocessor 240). The request 
may be transmitted via and XML gateway such as XML gateway 232 or XML gateway 234. 
The system (e.g., via XML processor 242) receives responses to the requests (e.g., XML 
response documents) from the one or more data sources in one or more formats other the 
particular format used by the client (e.g., phone 210). The system (e.g., via XML processor 
242) converts the responses into the particular format required by the client. Also, the 
system generates a composite response document in the particular format of the client based 
on the responses. For example, XML processor 242 may generate a single composite XML 
response document that is a composite of the individual XML response documents received 
from XML source 230, XML gateway 232, and XML gateway 234. (XML processor 242 is 
discussed further in page 10, line 15, through the end of page 12.) 

The system (via post processor 244) then transforms the composite response 
document into a response specifically formatted for the client based on a second set of 
parameters. The second set of parameters includes the identity of said particular type of 
client. Finally, the system (e.g., via post processor 244) transmits the client-formatted 
response to the particular user (e.g., phone 210). The client-formatted response may pass 
through gateway 202 and network 212 when being transmitted from the system to the client. 
(Postprocessor 244 is discussed at the top of page 13.) 
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In an embodiment, the transforming of the responses into the particular format of the 
client (described in the paragraph above) is performed by XSL engine 248. The transforming 
of the composite response document into a client specific format may be performed by the 
XSL engine 248 identifying one or more XSL stylesheets 250 based on the second set of 
parameters, and the XSL engine 248 applying the one or more XSL stylesheets 250 to the 
composite response document received from XML processor 242. (The XSL engine 248 is 
discussed on page 15, lines 7-19, and the XSL stylesheets 250 are discussed on page 14, line 
4, through page 15, line 6.) 

In an embodiment, the request object generated may include filter criteria. For 
example, the request from the client may be for a red car, and the data sources (e.g., XML 
source 230 and web server 1 10) may not support searching by color. Consequently a filter 
criteria corresponding to the color red will be embedded in the request object. Then after the 
system generates the composite response document (e.g., vi XML processor 242). The 
system (e.g., via filtering unit 246) filters the composite response document (e.g., returning 
only those cars listed in the composite response document that are red). Thus the search 
criteria submitted by the client and the search criteria used for searching the data sources may 
be different, and the data found by searching the data source based (using one set of search 
criteria) is then filtered based on another set of search criteria. (The filter unit 246 is 
discussed on page 13, line 9, through page 14, line 3.) 

In an embodiment, the one or more data sources include a first data source that 
supports a first protocol and is accessible through a first gateway, and a second data source 
that supports a second protocol and is accessible through a second gateway. The step of 
converting the responses into the particular format may include the first gateway converting a 
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response from the first data source to the particular format, and the second gateway 
converting a response from the second data source to the particular format. In an 
embodiment, at least one of said first data source and said second data source is a database 
system. In an embodiment, at least one of the first data source and the second data source is 
an HTTP server. In an embodiment, the client-formatted response is an HTML document. 
In an embodiment, the request object is an XML request document that includes unresolved 
links. In this embodiment, when the request is transmitted the unresolved links are resolved. In an 
embodiment, generating the composite response document involves replacing the unresolved links 
in the XML request document with XML data generated based on the responses from the one or 
more data sources. 

In an embodiment, data is sent to preprocessor 240 that indicates user-specific 
customizations for various services. Preprocessor 240 stores the data in a configuration database 
254. Then, in response to receiving the request for the service, configuration database 254 is 
searched by preprocessor 240 for the user-specific customizations. The preprocessor 240 includes 
the user-specific customizations in the first set of parameters, which are then used (by the 
preprocessor 240) to generate the request object. (See the discussion on page 9, line 6, through 
page 10, line 14) 

VI. ISSUES 

A. Whether claims 1-5, 8-11, 14-17, 21-24, 27-30, and 33-37 are patentable under 35 
U.S.C. § 103(a) over Nagatomo et al. (U.S. Patent No. 6,334,126) in view of Lincke et al. (U.S. 
Patent No. 6,397,259). 
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B. Whether claims 6, 7, 12, 13, 18-20, 25, 26, 31, and 32 are patentable under 35 U.S.C. § 
103(a) over Nagatomo et al. in view of Lincke et al. further in view of Bayeh et al. (U.S. Patent No. 
6,012,098). 

VII. GROUPING OF CLAIMS 

The claims should not be regarded as all standing together since the claims recite respective 
limitations that render each claim separately patentable. For this appeal, the following groups are 
recognized: 

1. Independent claims 1 and 22 and dependent claims 5, 11, 14, 24, 30, and 33. 

2. Dependent claim 3. 

3 . Dependent claims 4,21, and 23 

4. Independent claims 8-10 and 27-29 

5. Dependent claims 15 and 34 

6. Dependent claims 16 and 35 

7. Independent claim 17 and dependent claims 18, 20, and 21. 

8. Dependent claims 6, 7, 25, and 26 

9. Dependent claims 12 and 31 

10. Dependent claim 13 and 32 

1 1. Dependent claim 19 

Groups 1-7 relate to issue A, above, and Groups 8-1 1 relate to issue B, above. 
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VIII. ARGUMENT 

The arguments below are labeled hierarchically. Specifically, Groups 1-6 and claims 17 
and 21 of Group 7, above, are labeled as subgroups 1-7 of issue A, respectively, and Groups 8-11, 
above, are labeled as subgroups 1-4 of issue B, respectively. Additionally, claims 1 8-20 of Group 
7, above, is listed as subgroup 5 of issue B. 

A. CLAIMS 1-5, 8-11, 14-17, 21-24, 27-30, AND 33-37 ARE PATENTABLE UNDER 35 
U.S.C § 103(A) OVER NAGATOMO ET AL. IN VIEW OF LINCKE ET AL. 

1. Independent claims 1 and 22 dependent claims 3-5, 9, 10, 22-24, and 29 are not obvious 
over Nagatomo et al. (U.S. Patent No. 6,334,126) in view of Lincke et al. 
(a) Independent claim 1 

NAGAMOTO ET AL. 

All of the claims are rejected based on Nagamoto et al, taken in combination with other 
references. Nagamoto et al. discloses a data output system and method where a database holds data 
in voice, image, and text formats. After a search request from a client is processed, the search result 
is converted in accordance with the ability, function and capacity of the client, and is sent back to 
the client terminal. (Nagamoto et al., Abstract). 
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LINCKE ET AL. 

All of the claims are rejected based on Lincke et al., taken in combination with Nagamoto et 
al. The Office Action states that "Nagamoto et al. does not disclose said system generating, based 
on a first set of parameters, a request object". However, the Office Action (at page 5) alleges that 
in the same field of endeavor, Lincke et al. discloses "transforming the first message into a standard 
object data request, and transmitted the standard object data to the source of data". Lincke et al. 
discloses methods for "novel data compression techniques to enable wireless communications 
devices to complete transactions by exchanging a minimum number of data packets." In many 
circumstances, both the request and the response comprise a single packet. (Lincke et al., Abstract). 

Among other things, Claim 1 requires: 
. . . , 

within said system generating, based on a first set of parameters, a request object; 
wherein said first set of parameters includes identity of said service; 

... , 

at said system converting said responses into said particular format; 
at said system generating, based on said responses, a composite response document in said 
particular format; 

at said system transforming said composite response document into a client- formatted 

response based on a second set of parameters; 
wherein said second set of parameters includes identity of said particular type of client; and 

As shall be explained hereafter, Claim 1 is not obvious in light of Nagamoto et al., when 
taken in combination with Lincke et al., because neither Nagamoto et al. nor Lincke et al., taken 
alone or in combination, disclose or suggest any of the limitations recited above. 
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THE CLAIMS ARE NOT TO THE MERE CONCEPT OF CONVERTING DATA 
FORMATS BASED ON THE INTENDED RECIPIENTS CAPABILITIES 

As a preliminary matter, it should be noted that no attempt is being made to merely claim 
the idea of converting data from a format that cannot be used by the intended recipient of the data 
to a format that can be used by the intended recipient of the data. It is conceded that the system of 
Nagamoto et al. is a good example of a system that employs that general concept. 

For example, in col. 10, lines 59-64 and with reference to FIG. 5, Nagamoto et al. states that 

[w]hen the search result is image data and the communication terminal to which the 
search result should be sent (the transmission destination) does not have an image 
display function, for example, the controller 23 extracts text data associated with 
that image data and sends that text data as the search result. 

In other words, when the terminal cannot display an image, the image is converted to text. Further, 

in col. 10, line 65, to col. 11, line 3, and FIG. 5, Nagamoto et al. state that 

[w]hen the search result is text data whose amount exceeds the capacity of the 
communication terminal at the transmission destination, the text data generator 25 
edits that text data in such a way that the amount of the text data falls within the 
capacity of the destination's communication terminal. 

In other words, when the search result is a text too large to be displayed, the text is converted to a 

text of smaller size. Yet further, in col. 1 1, lines 3-8 and FIG. 5, Nagamoto et al. state that 

[w]hen the search result is text data and the communication terminal at the 
transmission destination has only a voice reproducing function, such as a telephone 
having no display device, the text-speech converter 26 converts the text data to 
voice data. 

In other words, when the terminal cannot display text data, the text data is converted to voice. And 

yet further, in col. 11, lines 9-16 and FIG. 5, Nagamoto et al. state that 

[w]hen the search result is image data compressed by a predetermined system (e.g. 
JPEG or GIF) and only an image compression/decompression program of another 
system is installed in the communication terminal at the transmission destination, 
the compression form converter 27 decompresses the image data and compresses 
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again the resultant image data by the system of the program installed in the 
destination's communication terminal. 

In other words, when the image cannot be displayed by the terminal, the image is converted into an 

image of a format that can be recognized by the terminal. 

In sum, Nagamoto et al. teach that, depending on the client terminal, the search results can 

be converted into at least the following formats: (1) text, (2) text of smaller size, (3) voice, and (4) 

image of different type. 

"Converting said responses into said particular format" 

The Office Action equates the conversions described in Nagamoto et al. with the limitation 
"at said system converting said responses into said particular format" recited in Claim 1. However, 
for the reasons given hereafter, the convert-to-client-supported- format operation described in 
Nagamoto et al. cannot possibly qualify as "at said system converting said responses into said 
particular format". 

Specifically, Nagamoto et al.'s convert-to-client-supported-format operation puts the data in 
a format supported by the intended recipient. In contrast, the claimed step of "at said system 
converting said responses into said particular format" does not. The fact that the "particular 
format" is not a format dictated by the capabilities of the client is clearly evidenced by the fact that 
the composite response document recited in Claim 1, which is in the "particular format", must be 
transformed in order to produce a "client- formatted response". Such a transformation would be 
unnecessary if the "particular format" of claim 1 was a client-specific format. 

In other words, the "particular format" recited in Claim 1 is clearly an intermediary format 
which is neither the native format of the responses received by the system (the responses are 
converted into the particular format), nor the client-specific format of the response documents 
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produced by the system (the composite response documents must be transformed before being 

transmitted to the clients). Nagamoto et al. does not disclose or in any way suggest converting 

responses into an intermediary format, and then converting from the intermediary format to a 

client-specific format. 

In response to the above argument, the Examiner (at page 12) stated, 

Nagatomo discloses in the Abstract and col. 10, line 30 - col. 1 1, line 35: the server 
receiving the results from the database 1, and performing conversion and edition on the 
search result in accordance with the ability (format or type of the communication terminal), 
function and/or capacity of the requesting communication terminal. 

However, the Examiner's response does not address the above point of the Appellants that claim 1 
recites a conversion to a particular format followed by a transformation from the particular format 
to client- formatted response. The single conversion to a client- format of Nagatomo et al. cannot be 
a conversion to a particular format that is not the client-format to which the particular response of 
claim 1 is later converted. 

"Generating a composite response document in said particular format" 

Nagamoto et al. does not describe generating a composite response document in the 

particular format based on the responses. The Office Action alleges that generating a "composite 

response document in said particular format" is described in Nagamoto et al., col. 10, line 30, to 

col. 1 1, line 35. However, Nagamoto et al. does not teach or in any way suggest generating a 

composite response document. In col. 10, lines 53-58 and with reference to FIG. 5, Nagamoto et 

al. explicitly states that 

the controller 23 works with a text data generator 25, a text speech converter 26 and 
a compression form converter 27 as needed to perform a predetermined process on 
data acquired from the database 1 as the search result, so that the search result can 
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be sent to the communication terminal at the transmission destination." (emphasis 
added). 

This paragraph, if anything, teaches that the search result is sent directly to the client terminal, and 

says nothing whatsoever about creating a composite response document based on the search result. 

Thus, the limitation of Claim 1 requiring the generation of "a composite response document in said 

particular format", is not described, or even suggested, by Nagamoto et al. 

In response to the above argument, the Examiner (at page 12) stated, 

Nagatomo discloses in col. 5, line 64 - col. 6, line 2, col. 6, lines 39-42, and col. 10, line 30 
- col. 1 1 , line 35: the server 2 converts the search result to another data format (a composite 
response document) in accordance with the ability or functions of the communication 
terminal at the destination. 

As will be shown below, although the Examiner is ostensibly addressing the appellants arguments 

presented in the response to the Final Office action, the Examiner fails to adequately address the 

above point that Nagamoto et al lack of a teaching of a "composite" response document. 

Specifically, column 5, line 64 through column 6, line 2, cited above, states, 

The server 2 sends out the search result to the network 3 after converting the search result to 
data expressed by another attribute or editing the search result, as needed, in accordance 
with the ability or functions of a communication terminal at a transmission destination 
(hereinafter sometimes referred to simply as "destination"). 

However, although the above passage discusses converting document formats, the above passage 

does not mention a "composite" document. A teaching of a conversion of a document format is not 

a teaching of a "composite" document. Similarly, column 6, lines 39-40, cited above, state 

The server 2 converts the search result to another data format or edits the search result, as 
needed, in accordance with the ability or functions of a communication terminal at the 
destination. 
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However, again although the above passage discusses converting document formats, the above 
passage does not mention a "composite" document based on composite "responses". Similarly, 
column 10, line 30, though column 11, line 35, states 

Since each communication terminal is retaining data on its ability and an OS and a 
program, both installed in itself, the communication terminal informs the server 2 of its own 
ability and function using the terminal ID code and program number in step S3 in FIG. 2 (or 
step SI 1 in FIG. 3). 

Upon reception of the terminal ID code and program number from each 
communication terminal, the server 2 can know the terminal ID code and program number 
of the communication terminal to which the search result should be sent (or maybe the 
communication terminal of the search requester) by referring to the access terminal memory 
22. 

The controller 23 analyzes the search request input via the I/O section 21 and 
accesses the database 1 to acquire the search result. 

Further, the controller 23 refers to a data attribute memory 24 shown in FIG. 8 to 
detect the attribute of data acquired from the database 1 as the search result The "data 
attribute 1 ' represents if each data in the database 1 is stored as image data, voice data or text 
data. 

When image data is stored together with text data associated with that image data as 
shown in FIG. 9, the data attribute becomes "image+text." 

Further, the controller 23 works with a text data generator 25, a text-speech 
converter 26 and a compression form converter 27 as needed to perform a predetermined 
process on data acquired from the database 1 as the search result, so that the search result 
can be sent to the communication terminal at the transmission destination. 

When the search result is image data and the communication terminal to which the 
search result should be sent (the transmission destination) does not have an image display 
function, for example, the controller 23 extracts text data associated with that image data 
and sends that text data as the search result. 

When the search result is text data whose amount exceeds the capacity of the 
communication terminal at the transmission destination, the text data generator 25 edits that 
text data in such a way that the amount of the text data falls within the capacity of the 
destination's communication terminal. 

When the search result is text data and the communication terminal at the 
transmission destination has only a voice reproducing function, such as a telephone having 
no display device, the text-speech converter 26 converts the text data to voice data. 

When the search result is image data compressed by a predetermined system (e.g., 
JPEG or GIF) and only an image compression/decompression program of another system is 
installed in the communication terminal at the transmission destination, the compression 
form converter 27 decompresses the image data and compresses again the resultant image 
data by the system of the program installed in the destination's communication terminal. 

The text data generator 25 converts and edits text data in accordance with an 
instruction from the controller 23. 
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The text-speech converter 26 converts text data to voice data in accordance with an 
instruction from the controller 23. 

The compression form converter 27 converts the data compression form in 
accordance with an instruction from the controller 23. 

The I/O section 21 is realized as functions of the program that are executed by the 
communication controller 14 and CPU 15 in FIG. 4. 

The controller 23, the text data generator 25, the text-speech converter 26 and the 
compression form converter 27 are realized as functions of the program that are executed by 
the CPU 15 in FIG. 4. 

The access terminal memory 22 and the data attribute memory 24 are set inside the 
memory 16 in FIG. 4. 

However, the above passage is over a column long making it difficult to determine what the 
Examiner believed would have lead one of ordinary skill in the art to use Nagamoto et al. system to 
form a composite response document. The Examiner also has not explained why each of these 
passages is cited, and what one passage might teach that another does not. Similarly, the Examiner 
has not given any rationale for how one of ordinary skill in the art might combine the above 
passages or infer from the above passages a teaching for a "composite" response document. 
Although it is acknowledged that each of the above passages discusses converting one format into 
another for receipt by the client, the above passage does not discuss forming a "composite" 
response document. 

The Examiner is apparently either ignoring the word "composite" or misinterpreting the 
word "composite". Regarding ignoring the word "composite", in the words of MPEP 2143.03, "To 
establish prima facie obviousness of a claimed invention, all the claim limitations must be taught or 
suggested by the prior art. In re Royka, 490 F.2d 981, 180 USPQ 580 (CCPA 1974)." Therefore, 
claim 1 would not have been obvious, because the Examiner has not shown any teaching or 
suggestion to generate a "composite" document within the device of Nagamoto et al. 

Regarding misinterpreting the word composite, the wording of the Examiner's above 
statement, "converts the search result to another data format (a composite response document)" 
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implies that the Examiner is confusing the word "composite" with the limitation of "another data 
format". However, the word "composite" does not mean "another" format or just any format. 
Webster's Revised Unabridged Dictionary, © 1996, 1998 MICRA, Inc. defines the adjective 
composite as "Made up of distinct parts or elements; compounded; as, a composite language" and 
contrary to the implications of the Examiner's assertions, does not define the adjective "composite" 
as generic to just any format or just any conversion to a new format. 
Further in this regard, claim 1 recites, 

at said system generating, based on said responses, a composite response document in said 
particular format; 

The "responses" upon which the "composite" is based is in the plural, which means that there are at 
least two of "said responses". Thus, claim 1 requires "generating... a composite response 
document" "based on said [at least two] responses. There is no disclosure, teaching or suggestion 
of taking at least two "responses", and then generating a "composite" response on the at least two 
"response" (before sending any of these responses to the client). 

Thus, in Nagamoto et al., in the absence of evidence to the contrary, it can be assumed that each 
individual response found is sent to the client without taking multiple responses and forming a 
composite response, which (after a later transformation) is later sent to the client. 

"Generating, based on first set of parameters, a request object" 

As shall be explained hereafter, Claim 1 is not obvious in light of Nagamoto et al., when 
taken in combination with Lincke et al., because "generating, based on a first set of parameters, a 
request object; wherein said first set of parameters includes identity of said service" is not 
described in Lincke et al. 
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Claim 1 requires generating a request object based on a first set of parameters, wherein the 
first set of parameters include the identity of the requested service. These limitations are very 
different from the transformation of a message into a "standard object data request" as described in 
Lincke et al. 

The Office Action asserts that Lincke et al. describes generating a standard object data 

request in col. 5, lines 9-65. However, nothing in this cited paragraph suggests that any 

parameters are used to generate a "standard object data request". In fact, Lincke et al. teaches 

"transforming" a first message into a standard object data request. In col. 5, lines 26-33, Lincke et 

al. state that the method of transforming a first message into a standard object data request 

. . . comprises combining the first message received from client processing resources 
with a hypertext markup language hyperlink document. The first message 
comprises field values and field indices corresponding to fields in the hypertext 
markup language hyperlink document. 

Thus, what Lincke et al. discloses is not generating a request object based on a first set of 

parameters that include the identity of a requested service as required by Claim 1 , but rather 

the transformation of a first message into a standard HTML document, where the transformation 

is predetermined since the message apparently is pre-formatted to contain only fields and indices 

that can be represented in the HTML document. There are no parameters involved in the 

transformation, and thus the transformation always produces the same standard request object. 

The notion that Lincke et al. describes transforming a message into a standard object data 

request without any parameters (much less parameters that include the identity of a requested 

service) is further strengthened by the paragraph in col 9, lines 59-65, which states, 

the [method for requesting data objects from a data source] comprises submitting 
compressed representations of field values and field indices, transmitting a first 
message in packets of data from a client to a server, transforming the first message 
into a standard object data request, and transmitting the standard object data request 
to the source of data. 
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Here, once again, a first message is pre-formatted to contain values and indices, and the message is 
subsequently transformed into a standard object data request. Nothing at all suggests that there 
might be parameters involved in the transformation, or that a different transformation is possible 
depending on the parameters. Furthermore, since there are no parameters involved in the 
transformation described in Lincke et al., there is not even a possibility that the identity of the 
service might be a part of the parameters. 

Thus, Lincke et al. does not disclose "generating, based on a first set of parameters, a 
request object; wherein said first parameter includes identity of said service" as required by Claim 
1. 

In response to the above argument, the Examiner stated, 

Lincke et al. discloses transmitting a first message (request) in packets of data from a client 
to a server, transforming the first message into a standard object data request, and 
transmitting the standard object data request to the source of data (col. 5, lines 9-65). 

However, the Examiner's comments did not address any of the issues raised above by the 

Appellants. The Examiner did not show where in column 5, lines 9-65, there is a teaching for a 

first set of parameters that includes an identity of a requested service or the generation of a request 

object based on a first set of parameters that includes the identity of the requested service. The 

Examiner did not comment on the lack of a discussion of the "transformation" of Lincke et al. 

being based on the first set of parameters in lines 26-33 and 59-65, discussed above by the 

Appellants, or the predetermined nature of the format into which the first message is transformed 

into a standard object request. The Appellants additionally note that column 5, lines 9-65, relied 

upon by the Examiner include six separate embodiments (which are (1) lines 9-25, (2) lines 26-33, 

(3) lines 34-40, (4) lines 41-52, (5) lines 53-57, and (6) lines 58-65), and the Examiner never 

explained whether these embodiments are relied upon in combination or in the alternative. If the 
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different embodiment are relied upon in the alternative, the Examiner has not explained how each 
of these embodiments is relied upon. If the embodiments are relied upon in combination the 
Examiner has not explained how these different embodiments are to be combined, which aspects of 
which embodiment are being relied upon for which claimed elements, and the motivation to 
combine these embodiments in what ever the manner is that the Examiner desired. 

With respect to the motivation to combine Lincke et al. and Nagamoto et al., the Office 
Action asserts that 

[s]ince Lincke et al. teaches a wireless communications system providing packet 
minimized communications between a wireless client and a proxy server, which is 
similar to a process of a communication terminal when a search requester requests a 
search for information in a database and the search result is returned to the search 
requesting communication terminal of Nagamoto et al., thus, it would have been 
obvious to one of ordinary skill in the art at the time the invention was made to 
combine the teachings of Lincke et al. and Nagamoto et al. to include generating a 
request object based on a set of parameters. 

In other words, the Office Action asserts that the motivation to combine the teachings of Lincke et 

al. and Nagamoto et al. arises out of the similarity between the two systems. However, it is clear 

that Lincke et al. and Nagamoto et al. address two entirely different problems. Lincke et al., on one 

hand, addresses the problem of minimizing communications to a wireless device by providing 

methods for data compression. Nagamoto et al., on the other hand, addresses the problem of 

servicing requests from a variety of client terminals with different functions and capabilities by 

providing mechanisms for converting text, image, and voice data. Thus, one with ordinary skill in 

the art would not be motivated to combine, with a reasonable probability of success, transforming a 

message into a "standard object data request" as described in Lincke et al. with the method and 

system as described in Nagamoto et al. 

In response to the Appellant's arguments, the Examiner (at page 13) wrote, 
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Since Lincke et al. teaches a wireless communications system providing packet minimized 
communications between a wireless client and a proxy server, which is similar to a process 
of a communication terminal when a search requester requests a search for information in a 
database and the search result is returned to the search requesting communication terminal 
of Nagatomo, thus, it would have been obvious to one of ordinary skill in the art at the time 
the invention was made to combine the teachings of Lincke et al. and Nagatomo to include 
generating a request object based on a set of parameters. Lincke et al. suggests that (sic) 
generating a request object to represent a form used for querying (sic) web server. 

However, the above response is essentially a repetition of the Examiner's original statement of 

rejection with the new line "Lincke et al. suggests that (sic) generating a request object to represent 

a form used for (sic) querying web server". However, this statement does not identify a motivation 

to combine, or address Lincke et al.'s lack of teaching of the claimed first set of parameters. The 

Examiner also does not address the difference in the problems addressed by Nagamoto et al. and 

Lincke et al. 

As explained above, Nagamoto et al. when taken in combination with Lincke et al., does 
not disclose or in any way suggest the Claim 1 steps of converting the responses into a particular 
format, generating a composite response document in the particular format based on the responses, 
and generating a request object based on a first set of parameters where the parameters include 
identity of the requested service. Therefore, it is respectfully submitted that Claim 1 is allowable 
over the art of record. 

(b) Claims 5, 11, 14, 22, 24, 30, and 33 

Claim 22 is the "computer-readable medium" form of Claim 1. This claim has limitations 
that correspond to those discussed above, and is therefore allowable for the same reason as Claim 
1. Claims 5, 1 1, 14, 24, 30, and 33 depend from one of claims 1 and 22, and are allowable for at 
least the same reasons. 
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2. CLAIM 3 

Claim 3 depends from claim 1. In addition to the reasons stated regarding claim 1, claim 3 
requires that 

one of said requests invokes a search mechanism at a data source based on a first set of 
search criteria; and the step of filtering data includes data that originated from said data 
source based on a second set of search criteria. ... 

While Nagamoto et al. do teach the use of a "search range" and a "keyword" as a search criteria 

used in the request sent to a data source (col. 8, lines 5-9) , Nagamoto et al. do not teach or in any 

way suggest employing a second set of criteria to filter data that originated from the data source. 

In response to the above argument, the Examiner (at page 14) stated, 

Nagatomo discloses in col. 2, lines 9-34, col. 7, line55 - col. 8, line 17, and col. 10, line 35 - 
col. 11, line 25: upon reception of the terminal ED code and program number (a second set 
of criteria) from each communication terminal, the server 2 can know the terminal ED code 
and program number of the communication terminal to which the search result should be 
sent to. 

Column 2, lines 9-34, cited above, states, 

Accordingly, it is an object of the present invention to provide a data output system, 
a communication terminal to be connected to a data output system, a data output method 
and a storage medium, which output data to be output as a search result after converting the 
format of the data to the data format requested by a receiving end, based on the contents of 
a request made by a search requester. 

Additionally, although the Examiner cited column 2, lines 9-34, the statements made by the 

Examiner following this citation do not explain its relevance. The Appellants assume that column 

2, lines 9-34, was cited because it states that an objective of Nagatomo et al. is to provide data to be 

output as a search result after converting the format of the data to a requested format. In other 

words, claim 3 recites filtering search results, while in contrast Nagatomo et al. teach formatting of 

the search results. Although both claim 3 and the above passage perform some sort of operation on 

search results, the two operations performed are very different. Specifically, "converting the 
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format" of data disclosed above by Nagatomo et al. is very different than the "filtering" of the data 
in claim 3. Converting the format implies that the data is somehow rearranged, but essentially all 
present. Filtering data implies that data that does not meet certain criterion, if present, is removed. 
Column 7, line 55, through column 8, line 17, cited above, states, 

In the data portion are stored a command, a terminal ID, a .terminal ED code and a 
program number or the like. 

A command instructs a process which is executed by a search-requested terminal 
(server 2). 

A search for information which is stored and managed in the database 1 is illustrated 
as such a command in this embodiment, but it is in no way restrictive, and any type of 
command can of course be used as long as the server 2 can execute it by using a program 
(e.g., CGI) which has been described by codes of a network language like Java. 

The terminal ED is an ED number of the local communication terminal (search 
requester). 

The terminal ED code represents the aforementioned ability of the local 
communication terminal. 

The program number represents the aforementioned function that the local 
communication terminal can carry out. 

When connection to the server 2 is established, the requesting communication 
terminal 4, 5 or 6 requests the server 2 to make a search by informing the contents of the 
search request, such as the search range and a keyword (step S4). 

In this flowchart, the processing order of the step S3 and step S4 may be reversed. 
Depending on the system structure of the network 3, reporting the ability or the like of the 
local communication terminal and the search request may be carried out simultaneously, or 
information indicating the ability or the like may be included in part of packet data (data 
portion). 

Although the above Examiner's statement about terminal ID is at least related to the above cited 
passage, the Examiner's statement and the above passage are unrelated to the subject matter recited 
in claim 3. The above passage is part of the discussion of FIG. 2B, and (in the words of column 7, 
lines 39-42) 

FIG. 2B is a structural diagram of packet data which is set on the network 3 at the time of 
informing the server 2 of the ability or the like of the search requesting communication 
terminal. 

A description of packet data is not a teaching of filtering the results of a search as recited in claim 
3. 
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Regarding column 10, line 25 through column 11, line 35, a copy of column 10, line 30, 
through column 11, lines 35, appears earlier in this Appeal Brief. As pointed out above, the length 
of this passage obscures the point the Examiner was trying to make by citing it. A discussion of 
formatting a search result is not relevant to filtering the search result. Similar to the Appellants 
earlier statements, the Examiner also has not explained why each of these passages is cited, and 
what one passage might teach that another does not. Additionally, the Examiner has not given any 
rationale for how one of ordinary skill in the art might combine the above passages or infer from 
the above passages a teaching for "filtering" a search. Although it is acknowledged that each of the 
above passages discusses converting one format into another for receipt by the client, the above 
passage does not discuss "filtering" a search document. 

3. CLAIMS 4,21, AND 23 
(a) Claim 4 

Claim 4 depends from claim 1. In addition to the reasons stated regarding claim 1, claim 4 
requires that "said first set of parameters for generating said request includes identity of said 
particular user." Nagamoto et al. do not teach that the identity of the particular user makes any 
difference in how a search result is processed. In col. 8, lines 1-4, Nagamoto et al. describe the use 
of a Terminal ID code to represent the ability of the communications terminal to present the search 
result, and the use of a program number to represent the functions that the communications 
terminal can carry out. However, the Terminal ED and the program number identify the client 
(depicted in FIG. 1 as PC 4, PDA 5, mobile phone 6, or pager 7), and NOT the identity of the 
particular user of the client (depicted in FIG. 1 as the search requester 8). 
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In response to the above arguments, the Examiner (at the paragraph bridging pages 14 and 
15) stated, 

Nagatomo discloses the use of a terminal ID code to represent the ability of the 
communications terminal to present the search result, and the use of a program number to 
represent the functions that the communications terminal carry out. Also, terminal ID and 
the program number identify the client as described in Fig. 1 as PC 4, PDA 5, or mobile 
phone 6, and thus the terminal ID and program number identify (sic) of a particular user of 
client (sic). 

However, the "terminal ID" clearly refers to a terminal, which is a "client" and not the "user" 
required by claim 4. The Examiner seems to identify the program number with a method of 
identifying the user. However, regarding the purpose of the program number, column 7, lines 26- 
29, state, 

In this case, the ability of each communication terminal is reported as a terminal 
identification (ID) code, while the functions are reported as a program number. 

Similarly, column 8, lines 3 and 4, state 

The program number represents the aforementioned function that the local 
communication terminal can carry out. 

Thus, the program number is used for keeping track of the "functions", i.e., the capabilities, 

associated with a "communication terminal". Additionally, column 9, line 66 though column 10, 

line 23 state, 

The access terminal memory 22 stores a terminal ED code and a program number, 
which have been discussed earlier with reference to FIGS. 2 and 3, in association with the 
ability and function of the associated communication terminal. 

FIG. 7 A is a structural diagram of an ID code table 221 provided in the access 
terminal memory 22. 

In the ID code table 221, individual terminal ID codes are stored in association with 
the abilities of the communication terminals. 

For example, the ID code table 221 shows that a communication terminal whose 
terminal ED code is "101" is a personal computer and has an image display function, a voice 
reproducing function and a text display function, with 2 MB indicated as the storage 
capacity for data on the search result. 

FIG. 7B is a structural diagram of a program table 222 provided in the access 
terminal memory 22. 
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In the program table, each program number, an OS (Operating System) which the 
associated communication terminal can invoke, and an application program (which is 
normally installed in that communication terminal or bundled at the time of installing the 
OS) are stored in association with one another. 

Thus, the program number is used to identify the "ability and function of the associated 

communication terminal", which is done by "In the program table, each program number, an OS 

(Operating System) which the associated communication terminal can invoke, and an application 

program ... are stored in association with one another" (see FIGs. 7A and 7B). Similarly, column 

13, lines 44-46, refer to "using the extracted program number as a key, to thereby recognize the OS 

and application program installed on that communication terminal". Thus, the program number is 

stored in association with the OS and application program on a communication terminal in order to 

keep track of the ability of that communication terminal. Consequently, in the above passages, 

Nagatomo et al. identify the program number with the capabilities of the communication terminal 

and not with the identity of the user. 

Similarly, column 10, lines 37 and 38, column 12, lines 20 and 21, column 13, lines 31 and 
32, and column 23, lines 1 and 2, refer to the "program number of the communication terminal" 
column 12, line 60, refers to the "program number of the pager terminal 7", and column 22, lines 
57 and 58, and "the program number corresponding to the communication terminal". Thus, the 
above clauses associate the program number with the pager terminal 7 and the communication 
terminal, which are clients. 

Although FIG. 1, cited above, shows a search requester 8, which may use PC4, PDA 5, 
telephone 6, or pager 7, there is no disclosure in FIG. 7 or in the discussion of FIG. 1 (i.e., column 
5, line 54, through column 6, line 58) of search requester 8 having an identification number or other 
identification. 
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Thus, the above Examiner's statements such as "terminal ID and the program number 
identify the client" do not address the Appellants' above point regarding claim 4 that the Terminal 
ID and the program number identify the client (depicted in FIG. 1 as PC 4, PDA 5, mobile phone 6, 
or pager 7), and NOT the identity of the particular user of the client (depicted in FIG. 1 as the 
search requester 8). Although some of the passages of Nagatomo et al. refer to a "search 
requester", none of the passages cited by the Examiner refer to the search requester having an 
identification. If anything, Nagatomo et al. seem to assume that by identifying the communication 
terminal used by the search requester, the search results will be returned to search requester. 
However, identifying a client (e.g., a phone or terminal) and identifying a user (e.g., Al Capone) are 
very different, because the user may switch clients (e.g., Al may throw away his phone or terminal 
and acquire a new one), or the client may change ownership and thereby switch users (e.g., Al 
Capone may suddenly die, and use of his phone may fall into someone else's hands). If the user is 
identified, switching clients does not change the identity, while if the client is identified, switching 
clients does change the identity. Additionally, identifying a client and "program number" and then 
finding the user, because by chance the same user (and not a different user) is still using the same 
client and its associated program number, is still identifying the client and its associated program 
number and not identifying the user. None of the passages cited above by the Examiner discuss 
identifying the user. Although the Examiner also states "and thus the terminal ID and program 
number identify (sic) of a particular user of client (sic)", the prior statements of the Examiner and 
the passages cited by the Examiner do not support this conclusion. 
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(b) Claims 21 and 23 

Claim 21 is a "system" claim that has limitations similar to those in Claim 4, and is 
therefore allowable for the same reason as Claim 4. Similarly, claim 23 is a "computer-readable 
medium" claim that has limitations similar to those in Claim 4, and is therefore allowable for the 
same reason as Claim 4. 


4. CLAIMS 8-10 AND 27-29 
(a) Claim 8 

Claim 8 requires, 

said one or more data sources include 

a first data source that supports a first protocol and is accessible through a 

first gateway, and 
a second data source that supports a second protocol and is accessible 

through a second gateway; and 
the step of converting said responses into said particular format includes 

said first gateway converting a response from said first data source to said 

particular format; and 
said second gateway converting a response from said second data source to 

said particular format. 

As pointed out in the Office Action, in col. 18, lines 25-67, Nagamoto et al. disclose a request 
made to a Web server instead of a database. However, nothing in Nagamoto et al. indicate or even 
suggest that two separate and structurally different data sources can be supported at the same time 
by the Nagamoto et al. system. While Nagamoto et al. disclose, in separate embodiments, the use 
of a database and a Web server as the data source, nothing indicates that a database and a Web 
Server can be used in the same embodiment of the Nagamoto et al. system. 

Furthermore, no two separate data sources, supported by two separate protocols and 
requiring conversion of responses according to two separate protocols, are disclosed in Lincke et al. 
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either. The paragraphs cited by the Office Action from Lincke et al., namely col. 9, lines 30-47 
(describing a Web server as a data source), col. 11, lines 8-25 (describing the function of a proxy 
connected to a single Web server), and col. 14, lines 48-64 (describing how CGI scripts operate), 
do not support the notion that Linke will suggest to one with ordinary skill in the art that two or 
more separate and structurally different data sources, supported by two separate protocols, can be 
used successfully in the system described by Nagamoto et al. 

In response to this argument, the Examiner (at page 15) stated, 

Nagatomo discloses a server 40 (gateway) converts data from either the database 1 (first 
data source) or World Wide Web 50 (second data source) (Figs. 1 and 16, col. 5, line 64 - 
col. 6, line 2, col. 6, lines 39-42, col. 10, line 30 - col. 11, line 35, and col. col. 18, lines 25- 
67: the server 2 converts the search result to another data format in accordance with the 
ability or functions of the communication terminal at the destination). 

However, column 5, line 64, though column 6, line 2, and column 6, lines 39-42, do not mention 

either of the database 1 or the World Wide Web 50. It is not clear why the Examiner cited these 

passages. 

Regarding the other passages cited by the Examiner, column 4, lines 46 and 47 state 

FIG. 1 is a structural diagram of a communication system to be adaptable to a first 
embodiment of this invention (emphasis added). 

In contrast column 5, lines 28-30, state 

FIG. 16 is a structural diagram of a communication system to be adaptable to a 
second embodiment of this invention (emphasis added). 

Similarly, the discussion of FIG. 16 appear after column 18, line 24, which is the heading, 

"SECOND EMBODIMENT", and the discussion of FIG. 1 is before this heading, implying that 

FIG. 1 is a description of the first embodiment. Although column 10, line 46, refers to "database 

1", column 10, line 30, through column 11, line 35, precede the heading "SECOND 

EMBODIMENT", and is therefore part of the discussion of the first embodiment. Consistent with 
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this, column 10, line 30, through column 11, line 35, does not refer to World Wide Web. Similarly, 
although column 18, lines 51 and 63, refer to WWW 50, column 18, lines 25-67, do not discuss 
database 1, and are clearly part of the second embodiment, which is consistent with column 18, 
lines 25-67, being located just under the heading "SECOND EMBODIMENT". 

Thus, the Examiner did not address the point of the above argument that the FIG. 1 is 
associated with the first embodiment and only has database 1 as a data source, but does not have 
the World Wide Web 50 as a data source, while FIG. 16 is associated with the second embodiment, 
which has the World Wide Web as the data source, but does not have database 1 as a data source. 
Additionally, the Examiner has not given any evidence that one or ordinary skill would have 
combined the two embodiments. 

(b) Claims 9, 10, and 27-29 

Claim 27 is a "computer-readable medium" claim that has limitations similar to those in 
Claim 8, and is therefore allowable for the same reason as Claim 8. Claims 9, 10, 28, and 29 
depend from one of claims 8 and 27, and are allowable for at least the same reasons. 
5. CLAIMS 15 AND 34 

(a) Claim 15 

Claim 15 requires the method of Claim 1 wherein: 

the method further comprises the steps of 

receiving data that indicates user-specific customizations to services; 
storing said data in a configuration database; 

searching said configuration database for said user-specific customizations in 
response to receiving said request for said service; 
said first set of parameters used to generate said request object includes said user-specific 
customizations. 

As pointed out in the discussion of Claim 4 above, nothing in Nagamoto et al. and Lincke et al. 
suggests that the identity of the user is used in any way by the Nagamoto et al. and Lincke et al. 
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systems. The paragraphs from Nagamoto et al. cited by the Office Action, namely col. 7, line 15 to 
col. 8, line 17 describe the capability and functions of the client (which, as defined by the 
Nagamoto et al. system in FIG. 1, can be a PC, PDA, mobile phone, or a pager), and not the user 
(described in Nagamoto et al. in FIG. 1 as the search requester 8) who is actually using the 
communication terminal. In direct contrast, Claim 15 requires receiving data that indicates user- 
specific customizations to services. 

Further, Claim 15 requires storing the user-specific customizations in a configuration 
database. Nothing in Nagamoto et al. even suggests that user-specific customization information 
is stored in a configuration database. The paragraph from Nagamoto et al. cited by the Office 
Action, col. 5, lines 55-60, describes a data source holding data in various formats, such as image, 
text, and voice. As described, the data source is not a configuration database, but it is rather the 
source of the data to which a search request is made. 

The Office Action further alleges that Nagamoto et al., in col. 6, lines 49-58, describes 
searching a configuration database for user-specific configurations. This is incorrect. The cited 
paragraph describes the operation of the Nagamoto et al. system with reference to FIG. 1: a search 
requester informs the server of in what format should the search result be transferred, and in 
accordance with this request the server obtains a search result from the data source and formats it in 
the proper format. In contrast, Claim 15 requires a configuration database holding user-specific 
customizations in addition to the basic requirements of searching a data source and returning 
results to a user as described in Claim 1. 

Finally, with respect to Claim 15, the Office Action alleges that Nagamoto et al., in col. 8, 
lines 5-10, describes using a first set of parameters, the parameters including user-specific 
customizations, to generate the request object. This is incorrect. The cited paragraph describe the 
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use of a "search range" and a "keyword" to perform the search of the data source itself, which is 
quite different from using user-specific customizations to generate a request object as required by 
Claim 15. 

In response the Examiner stated, 

Nagatomo discloses ED code (user-specific customization information) table 221 provided 
in the access terminal memory 22 (configuration database), which is located in the server 2. 

However, table 221 is FIG. 7A, and the only ID codes listed are in the far left column, which is 

clearly labeled "TERMINAL ID CODE". No user ID codes are present in table 221. Further, the 

remaining columns refer to properties of the terminal, and do not refer to the user. The Examiner 

did not respond to the remaining points raised in the above argument. 


(b) Claim 34 

Claim 34 is a "computer-readable medium" claim that has limitations similar to those in 
Claim 15, and is therefore allowable for the same reason as Claim 15. 


6. CLAIMS 16 AND 36 
(a) Claim 16 

Claim 16 requires, 

said one or more data sources include 

a first web site accessible through a gateway, and 

a second web site accessible through said gateway; and 
the step of converting said responses into said particular format includes 

said gateway converting a first response from said first web site to said particular 
format; and 

said gateway converting a second response from said second web site to said 
particular format. 
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Similarly to Claim 8, Claim 16 describes a method where there are at least two data sources, the 
two data sources being two websites accessible through a gateway. However, as pointed out in the 
discussion about Claim 8 above, nothing in Lincke et al. indicates that two websites can be used in 
the same embodiment as data sources. The paragraphs cited by the Office Action from Lincke et 
al., namely col. 9, lines 30-47 with reference to FIG. 1, describe only one Web server 140 as a data 
source, and a proxy server 180 providing the connection to a private wireless network 172. In 
contrast, Claim 16 requires two distinct websites as the data sources accessible through a gateway, 
where the gateway performs the conversion of the responses from the data sources. 

(b) Claim 35 

Claim 35 is a "computer-readable medium" claim that has limitations similar to those in 
Claim 16, and is therefore allowable for the same reason as Claim 16. 

7. CLAIMS 17 and 21 

(a) Independent claim 17 

Claim 17 is the "system" form of Claim 1. This claim has limitations that correspond to 
those discussed above, and is therefore allowable for the same reason as Claim 1 . 

Furthermore, Claim 17 is allowable since it includes separate elements defining the 
structure of the system which are not described in the cited references. 

Claim 17 requires: 

. . . , 

a request preprocessor, which is located separately from clients, . . .; 
said request processor operatively coupled to said request preprocessor and to one or more 
gateways, 

one or more gateways operatively coupled between said request processor and said data 
sources, 
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said post processor operatively coupled to said request processor, . . .; 

None of the cited references disclose, or even suggest, the use of a request preprocessor, request 
processor operatively coupled to the request preprocessor, one or more gateways operatively 
coupled between the request processor and the data sources, and post processor operatively coupled 
to the request processor. Therefore, it is respectfully submitted that Claim 17 is allowable over the 
art of record. 

In response to this argument, the Examiner (at page 14) wrote, 

Lincke et al. discloses the proxy server 180 represents one or more computers (request 
preprocessor, request processor, and post processor) that convert queries form the wireless 
communications device 100 into queries that are compatible with Internet protocols (col. 
10, line 66 -col. 11, line 26). 

Column 10, line 66, though column 1 1 line 26 state, 

The private network 1 72 represents the communications links between a base station 
170 and aproxy server 180. The BSMD Mobitex system has such a private network. 
Between the base station 170 and the proxy server 180, many servers, routers, and hubs, etc. 
may exist. In some embodiments, the private network 172 may communicate with the proxy 
server 180 through the Internet 190. The proxy server 180 would then communicate with 
the web server 140, also through the Internet 190. 

Although the proxy server is disclosed as being "one or more computers", there is no disclosure of 

how many computers the proxy server might be other than "one or more", which at best implies 

that the server computer can be "one" computer or can be "more". While it is conceded that 

"more" than one is at least two, a disclosure of "more" is not a disclosure of any other specific 

number. Although the Examiner states "proxy server 180 represents one or more computers 

(request preprocessor, request processor, and post processor)" and although the proxy server 180 

may be more than one computer, there is no disclosure of the possible different computers that 

make up the proxy server having the distinctly different functions of a "request preprocessor", a 
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"request processor" and a "post processor". Further, the passage cited by the Examiner does not 
mention a "gateway". 

(b) Claim 21 

Claim 21 is dependent upon claim 17, and is therefore allowable for at least the 

same reasons. 

B. CLAIMS 6, 7, 12, 13, 18-20, 25, 26, 31, AND 32 ARE PATENTABLE UNDER 35 ILS.C. § 
103(A) OVER NAGATOMO ET AL. IN VIEW OF LINCKE ET AL. FURTHER IN VIEW 
OF BAYEH ET AL. 

1. CLAIMS 6, 7, 25, AND 26 
(a) Claim 6 

Claim 6 requires the method of claim 1 wherein "the step of generating a composite 
response document in said particular format involves generating a composite response document in 
XML." The Office Action rejected Claim 6 under 35 U.S.C. 103(a) as being unpatentable over 
Nagamoto et al. and Lincke et al., and further in view of Bayeh. 

Bayeh describes a technique and a method for using servlets to isolate the retrieval of data 
from the rendering of the data into a presentation format. The data servlet formats its output data 
stream for transfer to a downstream servlet. The data stream may be formatted using language such 
as XML. The rendering servlet parses this XML stream, and using a XSL style sheet, creates an 
HTML data stream as an output. (Bayeh, Abstract). 
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The Office Action correctly points out that "Nagamoto et al.-Lincke et al. do not disclose 
the step of converting said responses into the particular format involves converting responses into 
XML and the step of generating a composite response document in the particular format involves 
generating a composite response document in XML." The Office Action further asserts that Bayeh 
discloses a data servlet that formats query results from a database to an XML. 

However, the Office Action incorrectly suggests that Bayeh describes generating a 

document in XML format. As pointed out in the discussion of Claim 1, Nagamoto et al. and 

Lincke et al. do not disclose generating a composite response document at all. Bayeh does not 

disclose generating a document in XML format either. In Bayeh, col. 8, lines 16-18 with reference 

to FIG. 4, it is stated that 

[i]n the preferred embodiment of the present invention, the data Servlet formats its 
output as an Extensible Markup Language ("XML") data stream." (emphasis 
added) 

Furthermore, in the Abstract Bayeh clearly suggests that a data stream, and not a document, is 
formatted into an XML format by stating that "[t]he rendering servlet parses this XML data 
stream". Yet further, in FIG. 4, the arrow pointing from the data servlet 83 to the rendering servlet 
85 is clearly and unmistakenly marked as "XML data stream." All this clearly shows that Bayeh 
does not disclose a document in an XML format, but rather a data stream in XML format used as 
a temporary intermediate output from the data servlet to the rendering servlet. 

In contrast, Claim 6 requires that a composite response document be generated in an XML 
format. The composite response document in XML format, as required by Claim 6, is 
fundamentally different from the data stream in XML format, as described in Bayeh, because while 
the composite response document is fixed and is itself transformed into a client- formatted response, 
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the data stream is a temporary intermediate which is used to create a separate response that is 

subsequently sent to the client. 

In response to the above argument, the Examiner (at page 16) stated 

Bayeh discloses data servlet formats query results (from a database) to an Extensible 
Markup Language (XML) (Abstract, col. 8, lines 3-29 and Figs. 4&5). 

However, the abstract states, 

A technique, system, and computer program for using servlets to isolate the retrieval of data 
from the rendering of the data into a presentation format. Data retrieval logic is isolated to a 
data servlet, and presentation formatting is isolated to a rendering servlet. Servlet chaining 
is used to send the output of the data servlet to the rendering servlet. The data servlet 
formats its output data stream for transfer to a downstream servlet. This data stream may be 
formatted using a language such as the Extensible Markup Language (XML), according to a 
specific Document Type Definition (DTD). The rendering servlet parses this XML data 
stream, using a style sheet that may be written using the Extensible Style Language (XSL), 
and creates a HyperText Markup Language (HTML) data stream as output. 

Although the last sentence of the abstract mentions an "XML data stream", an "XML document", 

is not disclosed. Similarly, column 8, lines 3-29, state 

In the programming model of FIG. 4, one of the types of servlet is referred to as a 
"data servlet" 83. The functionality of the data servlets is structured so that a data servlet 
retrieves data from a database. The role of the data servlet is only to retrieve data from a 
database 88': it does no presentation formatting of that retrieved data. The data servlet 83 
receives the search request 80', queries a database 88 f using database query statements 86' 
appropriate to the particular database, and receives the query results 90\ At that point, the 
data retrieval function of the data servlet 83 is complete. 

Before the data servlet 83 can pass data to another servlet for further processing, it 
must format that data in a manner that allows the next servlet to read and correctly interpret 
the data. In the preferred embodiment of the present invention, the data servlet formats its 
output as an Extensible Markup Language ("XML") data stream 97. XML is a standardized 
formatting notation, created for structured document interchange on the Web. XML is 
widely accepted in the industry, enabling the advantages of the present invention to be 
maximized. When the data servlet 83 formats its output into XML, and the next 
downstream servlet expects its input in XML format, the XML notation functions as a 
conduit, enabling a smooth transfer of data from one type of servlet to the other. A 
Document Type Definition ("DTD") 98, which may be stored on a medium such as a disk, 
is used when creating the XML data stream 97. 
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Again, although the above passage mentions an XML "data stream", no XML "document" is 
disclosed. Similarly, in FIG. 4, although data servlet 83 is illustrated as connected to rendering 
servlet 85 by an arrow labeled "XML data stream" and although in FIG. 5 step 260 recites "Fromat 
results as XML", step 270 recites send "XML data stream", and step 300 recites "Parse XML data 
stream", no XML "document" is disclosed. The fact that an XML "data stream" is sent in step 270 
and parsed in step 300, implies that the "data stream" is operated upon as is and is never converted 
into a "document". Thus, the Examiner does not address the distinction between the XML 
"document" of the claim and the XML "data stream" of Bayeh, which is the a point that was made 
above. 

(b) Claim 25 is a "computer-readable medium" claim that has limitations similar to those in 
Claim 6, and is therefore allowable for the same reason as Claim 6. Claims 7 and 26 depend from 
claims 6 and 25, respectively, and are allowable for at least the same reasons. 

2. CLAIMS 12 AND 31 
(a) Claim 12 

Claim 12 requires the method of Claim 6 wherein 

the step of generating a request object involves generating an XML request document that 

includes unresolved links; and 
the step of transmitting requests involves resolving said unresolved links. 

The Office Action alleges that Nagamoto et al, in col. 19, lines 7-19, and col. 19, line 59, to col. 

20, line 15, and further in view of Lincke et al. and Bayeh, disclose generating a request document 

including unresolved links. This is incorrect. In col. 9, lines 13-15, Nagamoto et al. describes that 
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[u]pon reception of the keyword to be searched from the [user], the controller 
searches the information providing table and sends a list of URLs corresponding to 
that keyword to the communication terminal. 

This paragraph clearly shows that Nagamoto et al. describes returning a list of URLs to the client 

terminal, and not, as required by Claim 12, generating a request object with unresolved links which 

links are to be resolved upon transmitting the responses to the client. 

(b) CLAIM 31 

Claim 31 is a "computer-readable medium" claim that has limitations similar to those in 
Claim 12, and is therefore allowable for the same reason as Claim 12. 

3. CLAIMS 13 AND 32 

(a) Claim 13 

Claim 13 depends from Claim 12, and further requires that "the step of generating said 
composite response document involves replacing said unresolved links in said XML request 
document with XML data generated based on said responses from said one or more data sources." 
As discussed above with respect with Claim 12, Nagamoto et al.-Lincke et al.-Bayeh do not 
describe generating a request document with unresolved links and resolving the links when the 
responses are transmitted to the client, so therefore Nagamoto et al.-Lincke et al.-Bayeh cannot 
possibly describe replacing the unresolved links with data generated based on the responses from 
the data sources as required by Claim 13. 

(b) CLAIM 32 

Claim 32 is a "computer-readable medium" claim that has limitations similar to those in 
Claim 13, and is therefore allowable for the same reason as Claim 13. 
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4. CLAIM 19 

Claim 19 is dependent upon claim 17, and is allowable for at least the same reasons. 
Additionally, as pointed out above Bayeh et al. disclose an XML datastream rather than an XML 
document as recited in claim 19. 

5. CLAIM 18 and 20 

Each of claims 18 and 20 are dependent upon claim 17, and are allowable for at least the 
same reasons. 
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IX. CONCLUSION AND PRAYER FOR RELIEF 

The Appellants have raised several points that show that the pending claims are patentable. 
Although the Examiner purports to answer the points raised by the Appellants, the arguments 
presented by the Examiner do not actually address the points raised. 

The rejections under 35 U.S.C. § 103(a) fail to establish prima facie obviousness for any 
pending claim. Applicant respectfully solicits the Honorable Board to reverse each of the imposed 


rejections. 
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X. APPENDIX 

CLAIMS 


1 1 . A method for retrieving information from one or more data sources, the method 

2 including the steps of: 

3 receiving, from a particular type of client, a request for a service; 

4 wherein said request for said service is received at a system located separately from 

5 said client; 

6 wherein said request is sent by a particular user; 

7 within said system generating, based on a first set of parameters, a request object; 

8 wherein said first set of parameters includes identity of said service; 

9 based on said request object, said system transmitting requests to one or more data 

10 sources; 

1 1 at said system receiving responses to said requests from said one or more data sources 

12 in one or more formats other than a particular format; 

13 at said system converting said responses into said particular format; 

14 at said system generating, based on said responses, a composite response document in 

1 5 said particular format; 

16 at said system transforming said composite response document into a client- formatted 

1 7 response based on a second set of parameters; 

1 8 wherein said second set of parameters includes identity of said particular type of 

19 client; and 

20 at said system transmitting said client-formatted response to said particular user. 

1 2. The method of Claim 1 further comprising the steps of 

2 embedding within said request object one or more filtering criteria, and 
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3 filtering data from said composite response document based on said filtering criteria 

4 prior to transforming said composite response document. 

1 3 . The method of Claim 2 wherein 

2 one of said requests invokes a search mechanism at a data source based on a first set 

3 of search criteria; and 

4 the step of filtering data includes filtering data that originated from said data source 

5 based on a second set of search criteria. 

1 4. The method of Claim 1 wherein said first set of parameters for generating said request 

2 object includes identity of said particular user. 

1 5. The method of Claim 1 wherein: 

2 the step of generating the request object includes generating filtering criteria; and 

3 the method includes filtering data from the composite response document based on 

4 the filtering criteria before transforming the composite response document. 

1 6. The method of Claim 1 wherein: 

2 the step of receiving responses to said requests from said one or more data sources in 

3 one or more formats other than a particular format involves receiving 

4 responses to said requests from said one or more data sources in one or more 

5 formats other than XML; 

6 the step of converting said responses into said particular format involves converting 

7 responses into XML; 

8 the step of generating a composite response document in said particular format 

9 involves generating a composite response document in XML; and 
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10 the step of transforming said composite response document into a client-formatted 

1 1 response involves transforming said composite response document into a 

1 2 format other than XML. 

1 7. The method of Claim 6 wherein the step of transforming includes: 

2 identifying one or more XSL stylesheets based on said second set of parameters; and 

3 applying said one or more XSL stylesheets to said composite response document. 

1 8. The method of Claim 1 wherein: 

2 said one or more data sources include 

3 a first data source that supports a first protocol and is accessible through a first 

4 gateway, and 

5 a second data source that supports a second protocol and is accessible through 

6 a second gateway; and 

7 the step of converting said responses into said particular format includes 

8 said first gateway converting a response from said first data source to said 

9 particular format; and 

10 said second gateway converting a response from said second data source to 

1 1 said particular format. 

1 9. The method of Claim 8 wherein at least one of said first data source and said second 

2 data source is a database system. 

1 10. The method of Claim 8 wherein at least one of said first data source and said second 

2 data source is an HTTP server. 

1 11. The method of Claim 10 wherein the client-formatted response is an HTML 

2 document. 
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1 12. The method of Claim 6 wherein: 

2 the step of generating a request object involves generating an XML request document 

3 that includes unresolved links; and 

4 the step of transmitting requests involves resolving said unresolved links. 

1 13. The method of Claim 12 wherein the step of generating said composite response 

2 document involves replacing said unresolved links in said XML request document 

3 with XML data generated based on said responses from said one or more data 

4 sources. 

1 14. The method of Claim 1 wherein said particular type of client is a mobile phone. 

1 15. The method of Claim 1 wherein: 

2 the method further comprises the steps of 

3 receiving data that indicates user-specific customizations to services; 

4 storing said data in a configuration database; 

5 searching said configuration database for said user-specific customizations in 

6 response to receiving said request for said service; 

7 said first set of parameters used to generate said request object includes said user- 

8 specific customizations. 

1 16. The method of Claim 1 wherein: 

2 said one or more data sources include 

3 a first web site accessible through a gateway, and 

4 a second web site accessible through said gateway; and 

5 the step of converting said responses into said particular format includes 
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6 said gateway converting a first response from said first web site to said 

7 particular format; and 

8 said gateway converting a second response from said second web site to said 

9 particular format. 

1 17. A system for transferring information between devices, the system comprising: 

2 a request preprocessor, which is located separately from clients, configured to 

3 receive service requests from said clients, 

4 generate request objects for said service requests, and 

5 pass said request objects to a request processor, which is located separately 

6 from said clients; 

7 said request processor operatively coupled to said request preprocessor and to one or 

8 more gateways, said request processor being configured to respond to said 

9 request objects by transmitting requests to data sources through said one or 

10 more gateways; 

1 1 said one or more gateways operatively coupled between said request processor and 

12 said data sources, said one or more gateways being configured to 

13 translate between a particular format and one or more other formats, 

14 convert said requests to said one or more other formats prior to issuing said 

1 5 requests to said data sources, 

16 convert responses from said data sources to said particular format, and 

17 pass said responses in said particular format to said request processor; 

18 wherein said request processor is further configured to generate composite response 

19 documents in said particular format based on said responses, and to pass said 

20 composite response documents to a post processor; 
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21 said post processor operatively coupled to said request processor, said post processor 

22 being configured to 

23 transform said composite response documents from said particular format to 

24 client-specific responses having formats required by clients, and 

25 transmit said client-specific response documents to said clients. 

1 18. The system of Claim 1 7 wherein said particular format is XML. 

1 19. The system of Claim 18 wherein the request objects are XML documents. 

1 20. The system of Claim 1 8 wherein the post processor includes an XSL engine that 

2 transforms said composite response documents by 

3 selecting one or more XSL stylesheets based on a first set of parameters, said first set 

4 of parameters including type of the clients; and 

5 applying said one or more XSL stylesheets. 

1 21 . The system of Claim 17 wherein the pre-processor generates the request objects based 

2 on a particular set of parameters, said particular set of parameters including identity 

3 of users that submit said service requests. 

1 22. A computer-readable medium bearing instructions for retrieving information from 

2 one or more data sources, the computer-readable medium including instructions for 

3 performing the steps of: 

4 receiving, from a particular type of client, a request for a service; 

5 wherein said request for said service is received at a system located separately from 

6 said client; 

7 wherein said request is sent by a particular user; 

8 within said system generating, based on a first set of parameters, a request object; 
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9 wherein said first set of parameters includes identity of said service; 

10 based on the request object, said system transmitting requests to one or more data 

1 1 sources; 

12 at said system receiving responses to said requests from said one or more data sources 

13 in one or more formats other than a particular format; 

14 at said system converting said responses into said particular format; 

15 at said system generating, based on said responses, a composite response document in 

1 6 said particular format; 

17 at said system transforming said composite response document into a client-formatted 

1 8 response based on a second set of parameters; 

19 wherein said second set of parameters includes identity of said particular type of 

20 client; and 

21 at said system transmitting said client-formatted response to said particular user. 

1 23. The computer-readable medium of Claim 22 wherein said first set of parameters for 

2 generating said request object includes identity of said particular user. 

1 24. The computer-readable medium of Claim 22 wherein: 

2 the step of generating the request object includes generating filtering criteria; 

3 the computer-readable medium includes instructions for filtering data from the 

4 composite response document based on the filtering criteria before 

5 transforming the composite response document. 

1 25. The computer-readable medium of Claim 22 wherein: 

2 the step of receiving responses to said requests from said one or more data sources in 

3 one or more formats other than a particular format involves receiving 
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4 responses to said requests from said one or more data sources in one or more 

5 formats other than XML; 

6 the step of converting said responses into said particular format involves converting 

7 responses into XML; 

8 the step of generating a composite response document in said particular format 

9 involves generating a composite response document in XML; and 

10 the step of transforming said composite response document into a client- formatted 

1 1 response involves transforming said composite response document into a 

1 2 format other than XML. 

1 26. The computer-readable medium of Claim 25 wherein the step of transforming 

2 includes: 

3 identifying one or more XSL stylesheets based on said second set of parameters; and 

4 applying said one or more XSL stylesheets to said composite response document. 

1 27. The computer-readable medium of Claim 22 wherein: 

2 said one or more data sources include 

3 a first data source that supports a first protocol and is accessible through a first 

4 gateway, and 

5 a second data source that supports a second protocol and is accessible through 

6 a second gateway; and 

7 the step of converting said responses into said particular format includes 

8 said first gateway converting a response from said first data source to said 

9 particular format; and 

10 said second gateway converting a response from said second data source to 

1 1 said particular format. 
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1 28. The computer-readable medium of Claim 27 wherein at least one of said first data 

2 source and said second data source is a database system. 

1 29. The computer-readable medium of Claim 27 wherein at least one of said first data 

2 source and said second data source is an HTTP server. 

1 30. The computer-readable medium of Claim 29 wherein the client-formatted response is 

2 an HTML document. 

1 31. The computer-readable medium of Claim 25 wherein: 

2 the step of generating a request object involves generating an XML request document 

3 that includes unresolved links; and 

4 the step of transmitting requests involves resolving said unresolved links. 

1 32. The computer-readable medium of Claim 3 1 wherein the step of generating said 

2 composite response document involves replacing said unresolved links in said XML 

3 request document with XML data generated based on said responses from said one or 

4 more data sources. 

1 33. The computer-readable medium of Claim 22 wherein said particular type of client is a 

2 mobile phone. 

1 34. The computer-readable medium of Claim 22 wherein: 

2 the computer-readable medium further comprises instructions for performing the 

3 steps of 

4 receiving data that indicates user-specific customizations to services; 

5 storing said data in a configuration database; 


Docket No. 50277-0312 
(OID 1999-020-01) 


50 


LONNROTH, Ser. No. 09/454,515 GAU 2176, Examiner Nguyen, Chau 
APPEAL BRIEF 


6 searching said configuration database for said user-specific customizations in 

7 response to receiving said request for said service; 

8 said first set of parameters used to generate said request object includes said user- 

9 specific customizations. 

1 35. The computer-readable medium of Claim 22 wherein: 

2 said one or more data sources include 

3 a first web site accessible through a gateway, and 

4 a second web site accessible through said gateway; and 

5 the step of converting said responses into said particular format includes 

6 said gateway converting a first response from said first web site to said 

7 particular format; and 

8 said gateway converting a second response from said second web site to said 

9 particular format. 

1 36. The method of Claim 1 wherein: 

2 said one or more data sources include a plurality of data sources; and 

3 said composite response document reflects information from each of said plurality of 

4 data sources. 

1 37. The computer-readable medium of Claim 22 wherein: 

2 said one or more data sources include a plurality of data sources; and 

3 said composite response document reflects information from each of said plurality of 

4 data sources. 
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